Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EKF2: Enable simultaneous optical flow and GPS use #4933

Closed
wants to merge 7 commits into from

Conversation

priseborough
Copy link
Contributor

@priseborough priseborough commented Oct 4, 2016

Enables simultaneous use of GPS and optical flow data with automatic fallback to relative position mode if GPS is lost and automatic switch-up to absolute position status if GPS gained/re-gained.

Parameter Settings

The EK2_RNG_USE_HGT was set to 50 so that below 50% of the range finders max range of 40m and when the vehicle is stationary, the range finder height is used as the primary EKF height reference. This is the preferred option for combined GPS and optical flow operation.
The EK2_GPS_TYPE was set to 0. Previously this would mean that optical flow data would be ignored, but now optical flow data will be used if a sensor is fitted and enabled by the FLOW_ENABLE parameter. Setting EK2_GPS_TYPE = 3 will still have the same effect as before, putting the EKF into an optical flow only mode that ignores GPS

Ground Testing

The ability to lose and regain GPS has been tested on the ground. The was conducted inside to provide a very marginal GPS signal. Placing a hand over the antenna was able to induce complete loss of GPS satellite tracking resulting in a switch to optical flow/relative position mode. When the GPS blockage was removed and the 3D lock recovered, the EKF reset its position to the GPS and switched to GPS mode. This was repeated twice.

GPS position accuracy - very poor and rises rapidly when 3D lock is lost
screen shot 2016-10-05 at 11 18 29 am

GPS position innovations - flat-lining indicates GPS is not being fused
screen shot 2016-10-05 at 11 18 44 am

Optical flow innovations - flow data was fused throughout
screen shot 2016-10-05 at 11 20 56 am

NE Position - note the position resets when GPS lock is regained.
screen shot 2016-10-05 at 11 21 49 am

Flight Testing

This branch has been flight tested on a 3DR Iris airframe with a PX4Flow v1.3 optical flow sensor and a Lightware SF10B range finder over flat terrain (sports field). The GPS was getting interference from the optical flow sensor with high levels of noise. The flight log can be found here: https://drive.google.com/file/d/0By4v2BuLAaCfeWtyd2xQTWxXZEE/view?usp=sharing

GPS reported speed error (m/s)
screen shot 2016-10-05 at 9 30 23 am

GPS reported position error (m)
screen shot 2016-10-05 at 9 36 34 am

Despite this, the copters position hold was steady throughout. The flight went through a range of speeds up to 5 m/s and altitudes up to 39m.

Optical flow innovations remained good throughout.

Optical flow innovations (mrad/sec)
screen shot 2016-10-05 at 9 33 25 am

GPS position and velocity innovations were high, reflecting the amount of interference. Normally GPS innovations this high would result in an unsteady position hold, but the optical flow fusion reduced the effect of the GPs errors on position and velocity output.

GPS position innovations (m)
screen shot 2016-10-05 at 9 34 51 am

GPS velocity innovations (m/s)
screen shot 2016-10-05 at 9 38 10 am

The automatic switching between range finder and Baro height can be seen in the height innovations. The periods of increased noise correspond to use of the Baro.
screen shot 2016-10-05 at 10 12 04 am

Enables simultaneous use of GPS and optical flow data with automatic fallback to relative position mode if GPS is lost and automatic switch-up to absolute position status if GPS gained/re-gained.
@OXINARF
Copy link
Member

OXINARF commented Oct 5, 2016

This is great Paul! The PR looks good to me, but let me point some places that might need to be modified too:

@OXINARF OXINARF added the EKF label Oct 5, 2016
@priseborough
Copy link
Contributor Author

@OXINARF in response to your review comments:

  1. It is intentional that we can use optical flow without setting GPS_TYPE to 3. setting GPS_TYPE to 3 now means that GPS won't be used. I will update the parameter description.
  2. I see the point - you are talking about being able to start the flight in relative aiding mode (I tested starting the flight in absolute aiding mode and then losing GPSt). I will change that line to permit going directly to relative aiding mode first.
  3. I think we should - as it would be good to know the optical flow is working properly before flying into an area where we know GPS will be lost. If the user doesn't want the EKf to use the optical flow, all they have to do is set FLOW_ENABLE to 0
  4. We wouldn't be using GPS in that instance because if frontend->_fusionModeGPS == 3 which means the user has explicitly requested the EKF not to use GPS.
  5. Likewise here - if frontend->_fusionModeGPS == 3 then GPS use has been prohibited by the user.

@priseborough
Copy link
Contributor Author

With the last commit 775a12a I am able to get the EKF to go into relative position mode at the start before getting GPS, but without GPS it won't let me arm in LOITER or select LOITER mode after arming, so further investigation is required.

@proficnc
Copy link
Contributor

proficnc commented Oct 5, 2016

Awesome job Paul! Been a long time in the works!
Now to dig out all the optical flow hardware!

@OXINARF
Copy link
Member

OXINARF commented Oct 5, 2016

@priseborough:

  1. I think you misunderstood me. I'm saying that in that place the variable optFlowNavPossible is dependable on GPS_TYPE being 3 and it shouldn't depend on it.

PR - agree, will fix.

  1. I agree. So will you change that? Is there any way to detect if flow was fused when we are absolute aid mode?

PR - thats easy because there is a flowDataValid flag that indicates the presence of fresh flow measurements

  1. I think you misunderstood me again (or I need to improve my English 😃). What I meant is: when should optical flow measurements be constrained to zero? Looking at that code, when we are on the ground. So my question is: if we are on the ground and GPS_TYPE != 3 but we are using optical flow we shouldn't constraint the measurements to 0?

PR - Ideally should if the distance to ground is less than a reasonable minimum focal distance, eg 50cm. We do want it to be possible to pick up the copter whilst disarmed and walk it around to both test the flow operation and also to be able to reposition it without the zeroed flow measurements fighting the GPS data.

  1. Same think, my question isn't about when GPS_TYPE == 3, but when it is different than 3. When it is different than 3 we can still be using optical flow and my question is if this detectOptFlowTakeoff should be called or not. Also my suggestion to change the check to the current aid mode is that we may have GPS_TYPE == 0 and be in relative aid mode: in this case I believe the detectOptFlowTakeoff function should be called anyway.

PR - If the logic used to zero the flow measurements is reworked to do so if optical flow takeoff is not detected and height above ground is less than 0.5m, then I believe it will address both points 4) and 5)

without GPS it won't let me arm in LOITER or select LOITER mode after arming, so further investigation is required.

I believe this is a pre-arm check problem. The Loiter mode is registered has needing GPS and so it won't let you arm until the GPS has passed all pre-arm checks (including being good enough for the EKF). But you should be able to arm in a non-GPS mode (Stabilize, AltHold) and then change to Loiter.

PR - agree

@priseborough
Copy link
Contributor Author

These patches address the review comments and have been test flown without a 3D GPS lock verifying that with ARMING_CHECKS=-9 the vehicle could be armed and flown in LOITER mode.

@OXINARF
Copy link
Member

OXINARF commented Oct 6, 2016

@priseborough Sorry for being a pain, but I'm not entirely convinced in the last case. Let's suppose that we have:

  • GPS_TYPE == 0
  • PV_AidingMode == AID_RELATIVE

Shouldn't the detectOptFlowTakeoff function run in this case? My though is that it would run when you exclusively use optical flow (because otherwise we wouldn't have a way to tell we took off - maybe this is where I'm wrong?).

…data

A specialised takeoff check is now always performed when we receive new flow data as the default behaviour is to try and use flow data whenever it is received, rather than limit its use to a use to a flow-only mode of operation that had to be selected via user parameter.
@priseborough
Copy link
Contributor Author

priseborough commented Oct 7, 2016

The (terrainState - stateStruct.position.z) < 0.5f) check in SelectFlowFusion will still operate (as it did during my testing), but I think it would be better to always run the specialised optical flow takeoff check when we receive flow data as it provides an earlier detection. I will add a patch that removes the condition so that detectOptFlowTakeoff() always gets called when new flow data arrives.

@rmackay9
Copy link
Contributor

Merged! Thanks very much @OXINARF for the review.

@roque-canales
Copy link

roque-canales commented Mar 3, 2017

2017-03-03 14-27-27.zip

Hello Paul,

I make flight with iris and SF11 + optical flow flying in loiter mode in AC3.5RC1 and standard ek2 settings.

During flight I test to go from no gps reception zone to gps zones, also, I flight over the ground and passing over roof of disused industrial building for see how ekf handle straight range finder changes.

Could you please check the logs and comment what you see and mayby tell us how to tune EK2 gates and noises for improve position holding and EK2 gps lidar optflow fuse?

Thanks you.

@magicrub
Copy link
Contributor

magicrub commented Mar 3, 2017 via email

@priseborough
Copy link
Contributor Author

@roque-canales Given that this is a log analysis request, can you please post your query here http://discuss.ardupilot.org/c/log-analysis-and-tuning/log-analysis-copter

@roque-canales
Copy link

roque-canales commented Mar 4, 2017

Ok Magicrub.

Ok Paul, thank you.

I just see that Randy found that EKF no recover position after glitch on AC3.5.

I experienced this issue on another AC3.5 flight.

When a glitch occur, drone start to drift, and no recover, even if gps back to g
2017-03-03 14-19-31.zip
ood situation, it's impossible to back to loiter. Also I think there's the same issue with AC3.4 and also for range finder/baro glitch.

@roque-canales
Copy link

EK3-CHALLENGING-ENVIRONEMENT-FLOW-SF11-GPSGLITCH.zip
I just flown EK3 over challenging environements.

I started from non gps zone, perfect,
to gps zone, flown over water and near wall of disused industrial building, perfect.

At the end of flight I go back to non gps zone, and EKF crashed i think, iris go to max lean angle, I switch to stabilise for regain control. (iris is robust and perfect for this tests. :))

It is like EK3 don't want to reject gps bad readings....

Maybe this issue just need to tune gate ore noise for gps?

And if it's the case, could you tell me new value for remake test flight?

@priseborough
Copy link
Contributor Author

@roque-canales Please raise your question here http://discuss.ardupilot.org/c/log-analysis-and-tuning/log-analysis-copter

This github issue is closed

@roque-canales
Copy link

ok sorry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants